This disclosure relates generally to computing systems, and more particularly to modeling properties of data and events of a computing system as transformations of document data and system values.
Properties of data and events are widely used particularly in UI applications. Properties have the main purpose to hide or modify the exposure of services the user cannot execute or shall not see, that is, they also guide the user (usability). Conventionally, properties of data and properties of events are handled as separate entities in user interfaces compared to the data attributes themselves. The communication channel to the user interface framework is also separated. There is a separate and dedicated communication channel and method to access dynamic properties, which are those properties that are not fixed for the respective data value or event, but depend on data (for example, a country associated with a sales order), user or system fields (such as a current date). Dynamic properties are computed by separate services within the business object services. Therefore, the logic as to how the dynamic properties are computed is hidden to the user interface frameworks.
This conventional approach has a number of drawbacks. First, it is not possible to easily shift a property calculation from one framework/execution layer to another. For example, if the data is supposed to be retrieved directly from an in-memory computing system database or a text-based search engine instead of from the business object (BO) service provider, then still the BO service provider must be invoked to compute the properties. This nullifies performance benefits of retrieving data directly from the in-memory database. The additional access of the BO service provider that is required basically offsets the new capabilities of the strictly in-memory approach.
Since easy shifting is not supported, it is also not possible to automatically provide a kind of “load balancing,” i.e. shifting the property calculation to the layer, where it is best suited for the current use case. The dependency between properties and data, user settings, or system fields is not transparent. This means also that a “where-used” list of the properties is not possible. The lack of transparency of these dependencies and how the properties are calculated hinders central framework optimization to can improve performance, supportability, maintenance costs, and/or operating costs.